-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
#3158 - [Jib core] Tar archives with same contents are not reproducible #3159
Conversation
…s are not reproducible
Have Jib CLI return correct version (GoogleContainerTools#3150)
Codecov Report
@@ Coverage Diff @@
## master #3159 +/- ##
============================================
+ Coverage 71.09% 71.25% +0.16%
- Complexity 2319 2329 +10
============================================
Files 279 279
Lines 9822 9850 +28
Branches 992 977 -15
============================================
+ Hits 6983 7019 +36
Misses 2493 2493
+ Partials 346 338 -8 Continue to review full report at Codecov.
|
I think this might be working as intended. Where are you encountering this as an issue that needs to be fixed? ReproducibleLayerBuilder adds in the behavior of reproducibility. |
The problem occurs when I create a Tar file using Jib My question is - should Jib produce a reproducible tar file when the input files are the same but the command has been run at a different time? |
Ah okay, I see. I think this needs to be solved in ImageTarBall's calls to TarStreamBuilder (#addByteEntry and #addBlobEntry). Those methods should be allowing a timestamp parameter. @chanseokoh does that make sense? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot for your contribution! I think we can accept the general direction to reset timestamps. Please check out the comment below.
jib-core/src/main/java/com/google/cloud/tools/jib/tar/TarStreamBuilder.java
Outdated
Show resolved
Hide resolved
Note to self: CHANGELOG |
@davidtron just checking in, do you plan to continue the work? |
… contents are not reproducible" This reverts commit 562e2b8
…s are not reproducible
@chanseokoh yes just updated the code to pull up to ImageTarball as suggested |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
Can you add some tests? I think its' not difficult to do so in TarStreamBuilderTest
, as I see other tests open a tar and go over TarArchiveEntry
?
jib-core/src/main/java/com/google/cloud/tools/jib/image/ImageTarball.java
Outdated
Show resolved
Hide resolved
jib-core/src/main/java/com/google/cloud/tools/jib/tar/TarStreamBuilder.java
Outdated
Show resolved
Hide resolved
jib-core/src/main/java/com/google/cloud/tools/jib/tar/TarStreamBuilder.java
Outdated
Show resolved
Hide resolved
jib-core/src/test/java/com/google/cloud/tools/jib/tar/TarStreamBuilderTest.java
Outdated
Show resolved
Hide resolved
jib-core/src/test/java/com/google/cloud/tools/jib/tar/TarStreamBuilderTest.java
Outdated
Show resolved
Hide resolved
…arball.java Co-authored-by: Chanseok Oh <[email protected]>
…mBuilderTest.java Co-authored-by: Chanseok Oh <[email protected]>
…mBuilderTest.java Co-authored-by: Chanseok Oh <[email protected]>
…mBuilder.java Co-authored-by: Chanseok Oh <[email protected]>
…mBuilder.java Co-authored-by: Chanseok Oh <[email protected]>
…s are not reproducible
…s are not reproducible
Just updating the test, I found that when we add a Just wondering if there is a clear way to articulate that in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Again, thanks for your contribution!
TarStreamBuilder
is completely independent of ReproducibleLayerBuilder
, so no need to bring that into your thinking. It's just that addTarArchiveEntry(TarArchiveEntry)
accepts a fully-built tar entry as-is (we should not manipulate the entry at all). OTOH, the other add methods internally create a new tar entry with the given properties, so it's only natural to set those properties.
So I'm not exactly sure how you're writing tests, but you can test all of them to check if they all work in the intended way. If addTarArchiveEntry(TarArchiveEntry)
adds an entry whose modTime is set to, say, 2021-04-09, then you can just check if the result tar archive has the very entry with the same modTime?
jib-core/src/main/java/com/google/cloud/tools/jib/tar/TarStreamBuilder.java
Outdated
Show resolved
Hide resolved
…s are not reproducible
…s are not reproducible
…s are not reproducible
…s are not reproducible
…s are not reproducible
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your contribution!
I actually wanted to have separate and dedicated unit tests, but given the back-and-forth, I can take care of it after merging this.
Fixes #3158.
Sets the mod time on TarArchiveEntry to DEFAULT_MODIFICATION_TIME (Epoch second 1) in order to create reproducible Tar images. Associated unit test creates 2 tars output streams from the same input 2 seconds apart to show the failure if we don't explicitly set the TarArchiveEntry mod time